The present invention relates to GPIB instrumentation systems, and more particularly to a system and method for performing autopolling of GPIB instruments using heuristic information for improved efficiency.
An instrument may be defined as a device which collects information from an environment and/or displays this information to a user. Examples of various types of instruments include oscilloscopes, digital multimeters, pressure sensors, etc. Types of information which might be collected by respective instruments include: voltage, resistance, distance, velocity, pressure, frequency of oscillation, humidity or temperature, among others.
The original GPIB was developed in the late 1960s by Hewlett-Packard (where it was called the HP-IB) to connect and control programmable instruments that Hewlett-Packard manufactured. With the introduction of digital controllers and programmable test equipment, the need arose for a standard, high-speed interface for communication between instruments and controllers from various vendors. In 1975, the Institute of Electrical and Electronic Engineers (IEEE) published ANSI/IEEE Standard 488-1975, IEEE Standard Digital Interface for Programmable Instrumentation, which contained the electrical, mechanical, and functional specifications of an interfacing system. The original IEEE 488-1975 was revised in 1978, primarily for editorial clarification and addendum. This bus is now used worldwide and is known by three names: General Purpose Interface Bus (GPIB), Hewlett-Packard Interface Bus (HP-IB), and IEEE 488 Bus.
The original ANSI IEEE 488 standard, now referred to as IEEE 488.1, was introduced in 1975 and greatly simplified the interconnection of programmable instruments by clearly defining mechanical, electrical and hardware protocol specifications. This enabled users to connect instruments from different manufacturers to a standard cable, thus allowing the instruments to communicate with each other. The original IEEE 488.1 standard dramatically improved the productivity of test engineers. However, this original standard included a number of limitations. More specifically, the IEEE 488.1 standard did not specify data formats, status reporting guidelines, a message exchange protocol, configuration commands, or a minimum set of device commands. As a result, different manufacturers implemented each item differently, resulting in integration problems for the test system developer.
In 1987, a new IEEE 488 standard for programmable instruments and devices was approved which strengthened the original IEEE 488.1 standard by precisely defining how controllers and instruments communicated with each other. The IEEE 488.2 standard kept the IEEE 488.1 standard completely intact while also defining standard data codes and formats, a status reporting model, a message exchange protocol, a set of common commands for all instruments, and controller requirements, therefore making systems more compatible and simplifying program development. In general, the IEEE 488.2 standard focuses on software protocol issues while the IEEE 488.1 standard is primarily hardware oriented.
Thus the IEEE 488 bus, also referred to as the General Purpose Instrumentation Bus (GPIB), is used for connecting instruments and controllers to a common bus to perform various test and measurement functions. The IEEE 488 Standard describes a standard interface for communication between instruments and controllers from various vendors. The IEEE 488.1 standard contains information about electrical, mechanical, and functional specifications. The GPIB is a digital, 8-bit parallel communications interface with data transfer rates of 1 Mbytes/s and above, using a 3-wire handshake. The bus supports one System Controller, usually a computer, and up to 14 additional instruments. The ANSI/IEEE Standard 488.2-1992 extends IEEE 488.1 by defining a bus communication protocol, a common set of data codes and formats, and a generic set of common device commands.
A typical GPIB system comprises one or more GPIB instruments, up to 14 instruments, and a controller, typically a GPIB interface board installed in a general purpose computer, connected by standard GPIB cables. A GPIB software application executes on the computer to control the instruments. The GPIB application interfaces through GPIB driver level software to the GPIB controller.
In response to the GPIB application, the controller provides program commands to the instruments, and the instruments return formatted data and response messages to the controller. GPIB instruments are message-based devices which are programmed with high-level ASCII character strings. A respective GPIB device includes a local processor that parses the command strings and sets the appropriate register bits to perform the indicated functions.
As noted above, a GPIB system includes GPIB driver level software which interfaces between a GPIB application and the GPIB hardware. The de facto standard for GPIB driver level software are the NI-488 and NI-488.2 software architectures, collectively referred to as the NI-488 software architecture, which is available in the NI-488 and NI-488.2 driver software products from National Instruments. The NI-488 software architecture includes an Application Programming Interface (API) which allows the GPIB application to call or invoke functions in the GPIB driver level software to communicate with the GPIB hardware. In other words, the GPIB driver level software handles the details of communication, i.e., the transfer of commands and data, over the GPIB connection between the computer and the GPIB instruments.
Autopolling
One function of a GPIB controller is to detect and respond to service requests from devices on the bus. The Service Request (SRQ) line on the GPIB is designed to signal the controller when a service request is pending. All devices share a single SRQ line. When a GPIB device asserts the SRQ line to request service, the controller must then determine which device is asserting the SRQ line and respond accordingly. The most common method for SRQ detection and servicing is the serial poll. Serial polling is a method of obtaining specific information from GPIB devices when they request service. When the controller serial polls the GPIB, the controller queries each device looking for the one that asserted SRQ. Each GPIB device responds to the poll by returning the value of its Status Byte. This Status Byte include one bit which indicates whether the device is asserting SRQ and 7 bits of other status information.
Some GPIB driver software programs, such as NI-488.2 driver software programs, have an internal feature called Automatic Serial Polling or Autopolling. If Autopolling is active and the SRQ line asserts, the driver will automatically 1) begin serial polling each device that has been opened by ibfind or ibdev, stopping when the SRQ line un-asserts; 2) store the serial poll response status byte(s) in a memory queue for later retrieval; and 3) set the RQS bit in the status word (ibsta) of each device that returned a status byte with Bit 6 set. The main advantage gained in using autopolling is that devices requesting service are polled as quickly as possible.
The controller may poll the eligible devices in any order it chooses. In prior art systems, the controller constructs a list of eligible devices in some arbitrary order. For example, the list of devices may be sorted in the order in which the controller was made aware of the devices. In another example, the list may be sorted by the GPIB address of the devices. During autopolling, the controller polls the devices in the listed order.
However, these approaches result in an arbitrary polling order, as mentioned above, and so the autopolling process may not poll the devices in an efficient manner. The polling stops when the controller locates the device asserting SRQ. Thus, the time required to complete a serial poll is related to the number of devices polled before SRQ unasserts. Therefore, improved systems and methods are desired for improving GPIB autopolling performance.
The present invention comprises various embodiments of a system and method for GPIB autopolling of GPIB devices. A GPIB instrumentation system may comprise a computer coupled to one or more GPIB instruments through a GPIB to analyze, measure or control a process or unit under test (UUT). The GPIB is coupled to the computer via a GPIB interface card which is typically plugged in to an I/O slot in the computer, such as a PCI bus slot, a PC Card slot, or an ISA, EISA or MicroChannel bus slot. Various other types of instruments may be comprised in the instrumentation system, such as a data acquisition board, a VXI instrument, or a serial instrument. The GPIB instruments are coupled to the process or unit under test (UUT), or are coupled to receive field signals, typically generated by transducers. The system may be used in data acquisition and control applications, in test and measurement applications, in process control applications, or in man-machine interface applications, among others.
The computer may comprise a CPU, memory, a display screen, and one or more input devices such as a mouse or keyboard. The computer preferably also includes a memory medium, such as a random access memory, which preferably stores a GPIB application and also stores GPIB driver level software according to one embodiment of the present invention. In the preferred embodiment, the GPIB driver level software is the NI-488.2 software available from National Instruments Corporation.
The software architecture for a GPIB instrumentation system may thus comprise a GPIB application program which interfaces through GPIB driver level software to one or more GPIB instruments. The top level of the software architecture typically comprises a GPIB application program used for high level control of the GPIB instruments. The GPIB application program may operate in conjunction with one or more instrument drivers to interface through the GPIB driver level software to the GPIB instruments.
The GPIB driver level software interfaces the commands or function calls in the GPIB application to the actual GPIB interface, or controller. In other words, in response to function calls made by the application, the GPIB driver level software communicates with the GPIB controller to control the GPIB instruments. In one embodiment, the GPIB driver software may also be operable to provide heuristic autopolling functions, described below.
In one embodiment of a GPIB heuristic autopolling process, the GPIB controller monitors activity of the GPIB devices on the bus. The GPIB controller may monitor any activity associated with each GPIB device, such as reads, writes, clear operations, device triggers, or any other activity associated with a GPIB device. In another embodiment, the GPIB controller may monitor a particular type of GPIB device activity, such as device service request (SRQ) line assertions.
The data generated by the monitoring process may be processed to produce heuristic information regarding the past behavior of the GPIB devices. The purpose of using heuristic information is to increase the probability (over uniform random chance) that the device responsible for the SRQ assertion will be polled first, or at least early on in the autopolling process. In a preferred embodiment, the heuristic information resulting from the above data processing may comprise a queue of the GPIB device IDs sorted according to a particular chosen heuristic.
The heuristic information (queue) may be generated and stored in the memory of the computer. In one embodiment old heuristic information may be periodically replaced with more recent information, thereby saving storage space as well as maintaining some level of relevance of the information. In other words, only heuristic information younger than some predetermined age may be maintained and used, thus the heuristic information may be periodically updated to reflect the recent history of the system. In another embodiment, the heuristic information stored may be limited to a particular amount of data. In this approach, after the stored information has reached a predetermined size or magnitude, old information may be deleted whenever new information is added, thereby maintaining a constant amount of heuristic information.
During operation of the GPIB system, a service request (SRQ) line assertion may be received or detected. The assertion may be triggered by one or more GPIB devices. The GPIB Controller may then perform autopolling on the GPIB devices to determine which of the devices asserted the SRQ. It is noted that autopolling refers to automatically polling the devices in response to receiving the SRQ assertion, i.e., the autopolling process is executed programmatically as opposed to being initiated by a user. The GPIB Controller may poll the devices in order according to the chosen heuristic, i.e., the order in which the devices are listed in the queue.
In one embodiment, the controller may maintain a queue of recently accessed devices, as mentioned above. A device may be considered accessed when any GPIB traffic is directed specifically to the device. For example, the controller may read or write data bytes to the device, or clear the device. The queue may have a constant depth N, where N is less than or equal to the number of eligible devices. Each entry in the queue may point to a unique (software description of a) device. For example, in the simplest case, each entry in the queue may comprise a device ID. The head of the queue points to the device most recently accessed. The next entry in the queue points to the second most recently accessed device, and so on. In other words, the queue entries may be sorted by how recently each device was accessed.
When the controller conducts an autopoll, the order of devices polled is the same as the order of devices in the queue. If none of the devices in the queue have asserted the SRQ, the controller polls all of the other devices in some arbitrary order. In the simplest case, N=1, i.e., the queue has a depth of one. After polling the most recently accessed device, the controller may poll the other devices in an arbitrary order.
In another embodiment, the controller may maintain a queue of devices that recently asserted SRQs (under the assumption that a device typically issues SRQs in clusters). As with the previous queue, the depth N of the queue is less than or equal to the number of eligible devices. In this embodiment, the head of the queue points to the device known to have most recently asserted SRQ. The next queue entry points to the next most recent device which has asserted SRQ, and so on. In other words, the queue entries may be sorted by how recently each device has asserted SRQ.
The controller may autopoll the devices in the order listed in the queue. As described above, if N is less than the number of eligible devices, the controller may poll the devices not in the queue in some arbitrary order. Again, in the simplest case N=1, so that if the device which most recently asserted SRQ is not responsible for the current SRQ assertion, the remainder of eligible devices may be polled in any order.
In other embodiments, other heuristics may be used as appropriate to improve the performance of the system. For example, other possible heuristics may involve combining the heuristics described above in various ways. The controller may maintain both queues (which may have different depths). The controller may alternate between the queues to choose devices to poll. The controller may also calculate the success of multiple heuristic techniques and dynamically choose different ones as their success in a particular system is recognized.
In the autopolling process, each device polled responds either positively or negatively. A positive response indicates that the device asserted the SRQ line. Once a device has given a positive response, it de-asserts the SRQ line. In one embodiment, multiple devices may assert the SRQ line concurrently. In this case the controller may autopoll the devices as described above, and upon receiving a positive response from a device indicating that the device asserted the SRQ, check the status of the SRQ line. If the SRQ line is still asserted, the controller may continue the autopolling process until all asserting devices have been identified. If all of the devices have been polled and the line remains asserted, an error condition may be indicated.
Thus, the system and method described above may improve GPIB autopolling performance by applying heuristics based on the activity history of GPIB devices to determine the order in which the GPIB devices are autopolled, thus shortening the expected (or average) time required to identify asserting GPIB devices.